fwk: keyboard: opt-in Fn-lock indicator on Caps Lock LED; fix lost auto backlight - #87
Open
AlexTu2 wants to merge 2 commits into
Open
fwk: keyboard: opt-in Fn-lock indicator on Caps Lock LED; fix lost auto backlight#87AlexTu2 wants to merge 2 commits into
AlexTu2 wants to merge 2 commits into
Conversation
board_kblight_init() masks KB_FN_LOCKED off the BBRAM byte before calling kblight_set(), but compares the unmasked byte against KEYBOARD_BL_BRIGHTNESS_AUTO (101). fnkey_shutdown() stores the Fn-lock flag in bit 7 of that same byte, so with Fn lock enabled the stored value is 101 | 0x80 = 229, the compare never matches, and auto keyboard backlight is silently lost on every boot for anyone who leaves Fn lock on. Apply KB_BRIGHTNESS_MASK before the compare, and use the existing macro in place of the literal 0x7F on the line above. Tested on a Framework Laptop 13 Pro (sakura), together with the following commit: with Fn lock on and the keyboard backlight set to auto (Fn+Space), auto is retained across a reboot. Also builds for azalea and marigold, which share this file; not tested on their hardware. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014dAnHutxgoW4y9K7DAZomY
Fn lock (Fn+Esc) is tracked only inside the EC: there is no host command or HID report for it, so there is no way to tell which state the top row is in without pressing a key. See FrameworkComputer/SoftwareFirmwareIssueTracker#176 Add CONFIG_PLATFORM_EC_FRAMEWORK_FNLOCK_CAPS_LED (default n). When enabled, gpio_cap_led follows Fn_key & FN_LOCKED instead of the host's 8042 Caps Lock state, using the existing lid/S0 blanking in keyboard_caps_led_update(). With the option off, LED behaviour is unchanged. Independently of the option, persist the Fn-lock flag to BBRAM on every toggle rather than only in fnkey_shutdown(), so an unclean power loss does not restore whatever the last clean shutdown stored. fnkey_save_kbstate() is factored out of fnkey_shutdown() for this; Fn_key moves above the LED code so the updater can read it. Boot-time restore relies on HOOK_CHIPSET_RESUME: HOOK_CHIPSET_STARTUP fires while power_get_state() is still POWER_S5S3, which the blanking rejects, so a call from fnkey_startup() would always write 0. A comment says so. Tested on a Framework Laptop 13 Pro (sakura) with the option enabled. That build is byte-identical to the image flashed for testing. - Fn+Esc toggles the LED - the LED goes dark with the lid closed and returns when it is opened - the LED is dark in suspend and returns on wake - Fn lock and the LED state are restored after a reboot Not tested: restoring the Fn-lock flag after an unclean power loss, and any hardware other than sakura. With the option off, sakura, azalea and marigold build, but that configuration was not run on hardware. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014dAnHutxgoW4y9K7DAZomY
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The EC never tells the host whether Fn lock (Fn+Esc) is on: there's no host command and no HID report for it (see FrameworkComputer/SoftwareFirmwareIssueTracker#176). So you can't tell which state the top row is in without pressing a key. This PR adds an opt-in build option that shows Fn lock on the Caps Lock key's LED. It also fixes a bug in the same file that bites anyone who leaves Fn lock on.
Two commits, so the fix can be taken without the feature:
board_kblight_init()compares the BBRAM byte toKEYBOARD_BL_BRIGHTNESS_AUTO(101) without masking offKB_FN_LOCKED(bit 7). With Fn lock on, the stored value is 229, the compare never matches, and auto keyboard backlight is lost on every boot. The fix masks the byte before comparing.CONFIG_PLATFORM_EC_FRAMEWORK_FNLOCK_CAPS_LED(defaultn, depends onPLATFORM_EC_FRAMEWORK_LAPTOP_13). When it's enabled,gpio_cap_ledfollowsFn_key & FN_LOCKEDinstead of Caps Lock. It keeps the existing lid/S0 blanking inkeyboard_caps_led_update(), and Caps Lock gets no indicator. When it's off, LED behaviour is unchanged. Separately from the option, the Fn-lock flag is now written to BBRAM on every toggle, not only infnkey_shutdown().To enable it on a board, add this to its
project.conf:Testing
On a Framework Laptop 13 Pro (sakura), with the option enabled. That build is byte-identical to the image flashed for these tests.
Builds with the option off: sakura, azalea, marigold.
Not tested: restoring the Fn-lock flag after an unclean power loss; the option-off configuration on hardware; any hardware other than sakura.
Notes
HOOK_CHIPSET_RESUME, notfnkey_startup().HOOK_CHIPSET_STARTUPfires whilepower_get_state()is stillPOWER_S5S3, and the blanking rejects that state. There's a comment in the code about this.flake.nixpointszephyratssh://git@github.com/FrameworkComputer/zephyr-ec, which isn't reachable from outside. The pinned revision8bdbcbbis public asFrameworkComputer/zephyrbranchfwk-sakura-20260429. On sakura the EC runs its RO copy, so flashing needsframework_tool --flash-ec --force(RO+RW), and RO has no software fallback. Dump your stock flash first.Cherry-pick status (the template lists
fwk-main, which doesn't exist; this PR targetsfwk-sakura-20260429):🤖 Generated with Claude Code
https://claude.ai/code/session_014dAnHutxgoW4y9K7DAZomY